Managing NFS and NIS, 2nd Edition by Mike Eisler; Ricardo Labiaga; Hal Stern

Author:Mike Eisler; Ricardo Labiaga; Hal Stern
Language: eng
Format: mobi
Tags: Reference:Computers
ISBN: 2152316770
Publisher: O'Reilly Media
Published: 2009-02-09T10:00:00+00:00

Using netgroups

Netgroups have been used in several examples already to show how triples of host, user, and domain names are used in granting access across the network. The best use of netgroups is for the definition of splinter groups of a large NIS domain, where creating a separate NIS domain would not justify the administrative effort required to keep the two domains synchronized.

Because of the variety of ways in which netgroups are applied, their use and administration are sometimes counterintuitive. Perhaps the most common mistake is defining a netgroup with host or usernames not present in the NIS maps or local host and password files. Consider a netgroup that includes a hostname in another NIS domain:

remote-hosts (poi,-,-), (muban,-,-)

When a user attempts to rlogin from host poi, the local server-side daemon attempts to find the hostname corresponding to the IP address of the originating host. If poi cannot be found in the NIS hosts.byaddr map, then an IP address, instead of a hostname, is passed to ruserok( ). The verification process fails to match the hostname, even though it appears in the netgroup. Any time information is shared between NIS domains, the appropriate entries must appear in both NIS maps for the netgroup construction to function as expected.

Even though netgroups are specified as host and user pairs, no utility uses both names together. There is no difference between the following two netgroups:

group-a (los, mikel,) (bitatron, stern, )

group-b (los, -,) (bitatron, -,) (-, mikel, ) (-, stern, )

Things that need hostnames — the first column of hosts.equiv or NFS export lists — produce the set of hosts {los, bitatron} from both netgroups. Similarly, anything that takes a username, such as the password file or the second column of hosts.equiv, always finds the set {mikel, stern}. You can even mix-and-match these two groups in hosts.equiv. All four of the combinations of the two netgroups, when used in both columns of hosts.equiv, produce the same net effect: users stern and mikel are trusted on hosts bitatron and los.

The triple-based format of the netgroups map clouds the real function of the netgroups. Because all utilities parse either host or usernames, you will find it helpful to define netgroups that contain only host or usernames. It's easier to remember what each group is supposed to do, and the time required to administer a few extra netgroups will be more than made up by time not wasted chasing down strange permission problems that arise from the way the netgroups map is used.

An example here helps to show how the netgroup map can produce unexpected results. We'll build a netgroup containing a list of users and hosts that we trust on a server named gate. Users in the netgroup will be able to log in to gate, and hosts in the netgroup will be able to mount filesystems from it. The netgroup definition looks like this:

gate-group (,stern,), (,johnc,), (bitatron, -,), (corvette, -,)

In the /etc/dfs/dfstab file on gate, we'll add a host access restriction:

share -o rw=gate-group /export/home/gate

No at-sign (@) is needed to include the netgroup name in the /etc/dfs/dfstab file.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.